Eagles Nest BBS 7

home *** CD-ROM | disk | FTP | other *** search

/ Eagles Nest BBS 7 / Eagles_Nest_Mac_Collection_Disc_7.TOAST / Internet⁄Other Nets / TelecomF11 / Telecom F1.1 - Internet Info / Internet Info ƒ / bitnet info next >

Wrap

Internet Message Format | 1991-01-22 | 45KB

From: B_FOLEY@UVMVAX.BITNET Subject: Document for beginners using BITNET From: IN%"BIO-NAUT@IRLEARN.UCD.IE" 15-OCT-1990 02:49:18.61 Subj: BioBit No 17 (Bitnet for the complete idiot) 1717171717 1717171717 1717171717 1717171717 171 171 171 171 171717171 171 1717171717 171717171 171 171717171 171717171 1717171717 171717171 171 171 171 171 171 171 171 171 171 171 1717171717 171 1717171717 1717171717 171 171 1717171717 171 1717171717 1717171717 171 171 No 17 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% INDEPENDENT "bionaut" NEWSLETTER << EDITED BY ROBERT HARPER >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Summer is over. Good things are happening on the net once again. There has been a new release of "BITNET for the complete idiot". Things are therefore not too bad. I know I did not write this network clasic. I know it is long... but it is so good and covers so many things, it would be a waste not to give it some airplay. And since the documentation says that if you inform the author you can include it in a newsletter then that is enough justification to put it out on BIONAUT.... RIGHT!!! No more talk. Ladies and gentlemen may I present for your education, edification and entertainment the one... the only... BITNET USERHELP. Rob "standing on the shoulders of a giant you see much further" Harper _ __- __--- The __----- BITNET __------- Services ___________ Library BITNET USERHELP ******************************************************************************* August, 1989 "Oh no! Another Version of the Completely Revised Edition" This document has been written for new users of BITNET services. A quick perusal of the text here should familiarize you with the basic concepts behind BITNET and how to communicate with people through it. A longer look will show you the many types of information services available in the network and explain how to access them. If the information presented here is confusing or incomplete, please send a note to the author, Christopher Condon, at address BITLIB@YALEVM. Likewise, if you find this document useful and would like to reprint it in part or whole, (in a newsletter or local documentation, for example) we have no objection as long as you inform the author. A companion file to this is BITNET SERVERS, which lists the currently available servers and services. Instructions for receiving the latest versions of SERVERS and USERHELP appear at the bottom of this document. In addition to these files, you should consult your local computer center staff and online documentation for additional information. Here is a rundown of the topics covered: 1. Tools for Communication BITNET for the Compleat Idiot Messages Files Mail 2. Servers and Services What the Heck is a Server, Anyway? File Servers User Directory Servers Forums, Digests, and Electronic Magazines List Servers Relays 3. Beyond BITNET Other Networks More on Gateways 4. In Conclusion Suggested Reading ********* * * Tools for Communication * * * * Part 1 * * * * BITNET for the Compleat Idiot ********* If you intend to make any sense out of this document, you should first have a basic understanding of some computer concepts: mainframes, userids, and the like. Since you are reading this there is a pretty good chance that you understand these things already. If not, go back, read some documentation on your system, get comfortable with "logging on", "editing", and all those other fun activities and *then* you can begin communicating through BITNET. The concepts we present here aren't terribly Earth-shattering, but you shouldn't dive into this totally unprepared either. You should also be a little familiar with the type of hardware and operating system you are using. Most IBM systems in BITNET run VM/CMS. The Digital Equipment VAX systems usually run an operating system called VMS along with a software package called JNET which allows them to communicate via BITNET. We will be referring to VM/CMS and VMS/JNET throughout this document. If you already understand computer networking, you will find this section entirely dull and pedantic. We would advise you to skip to the next part, "Messages". For the rest of you, we'll try to make this quick and painless. The word "computer" still scares many people. When BITNET is described simply as a "computer network", that one word can send chills up your spine. Sometimes a phrase like "communications medium" can make the technology a little more accessible. That is how we like to think of it. It's not some awful computer-techie sort of thing. Rather, it's a tool for communicating with people and exchanging information, just like your telephone, only a little more complex. This doesn't mean that there isn't a lot of gee-whiz technical stuff behind BITNET. If that is the sort of thing that tickles your fancy, you'll find it in this network. The rest of you, however, don't need to know the gory details in order to use BITNET effectively. That mainframe you log onto is connected to mainframes at other universities and institutions. The connection is usually a high-speed leased line, a special sort of telephone connection. You might say that these computers are always on the phone with each other. Our particular network is what is known as a "store and forward" network. This means that if I send something to someone in Los Angeles, the computers in the network between Connecticut and California will store and forward it from computer to computer until it reaches it's destination. In BITNET, there is only one way from "Point A" to "Point B". A small piece of the network might look like this: --- --- --- | A |--| B |--| C | --- --- --- | --- --- --- --- --- | D |--| E |--| F |--| G |--| H | --- --- --- --- --- | | --- --- --- --- | I |--| J | | K |--| L | --- --- --- --- | --- --- | M |--| N | --- --- Those boxes represent computers in the network, and the dashes between them are the leased lines. If I am at computer "A" and I send a file to someone at computer "N" it would travel the following path: A-B-D-E-F-G-K-N Each of the computers in BITNET is called a "node" and has a unique name that identifies it to the other nodes. For example, one of the mainframe computers at Yale has the nodename YALEVM. You might liken this to a state or country abbreviation: In the postal service: CT = Connecticut In BITNET: YALEVM = Yale University IBM 3083 Your userid in combination with the name of your node is your "network address". It is usually written in the format userid@node (read "userid at node"). For example, the name of my node is YALEVM, and my userid is CONDON. Therefore, my network address is CONDON@YALEVM. If I know the userid@node of someone in the network, I can communicate with that person, and he/she can communicate with me. The same goes for you. All you need to know are a few commands. ********* * * Tools for Communication * * * * Part 2 * * * * Messages ********* There are three basic methods of communicating via BITNET: MESSAGE, FILE, and MAIL. The reason you would choose one over the other for a particular application will become clear after a little explanation. The MESSAGE (sometimes called "interactive message") is the fastest and most convenient method of communication available through BITNET. It is the network's equivalent of a telephone conversation. The difference is that the words are typed instead of spoken. The message you type is transmitted immediately (well, quickly) to its destination. In BITNET this destination is the network address (userid@node) of the person you want to contact. If the person you are contacting is logged on, the message will be displayed on their screen. If not, their computer will tell you so. In this case, your message is lost forever. In other words, no one is there to answer the phone. However, many people run a program which will act like an answering machine and hold your message until they log on. The syntax to send messages depends on your computer and system software. People on VM/CMS systems would type something like this: TELL userid AT node message For example: TELL KRISTEN AT MARIST Hey Kristen, What's up? +------ +----- +---------------------- | | | | | +----------- the message you are sending | | | +------------------ the node of the recipient | +----------------------------- the userid of the recipient People on VAX/VMS systems using the JNET networking software would use this syntax: SEND userid@node "message" For example: SEND KRISTEN@MARIST "Hey Kristen, What's up?" +------ +----- +------------------------ | | | | | +-------------- the message you are sending | | | +--------------------- the node of the recipient | +----------------------------- the userid of the recipient The quotes around the message are optional. However, the JNET networking for VAX/VMS will translate your entire message into upper-case characters if you DO NOT use them. Many people find receiving messages like that extremely annoying. You should consult your local system documentation for more information on TELL or SEND and their capabilities. When a message arrives on your screen, it will look something like this: FROM MARIST(KRISTEN): Hello! It's been a while, no? Now for the disadvantages: Text sent by message must be short. In general, your message length can be one line, about the width of your screen. In other words, you won't be sending someone a copy of your thesis via the TELL command. Also, you can only communicate with someone in this way when they are logged on. Considering time zone differences, this is often quite inconvenient. Lastly, there is the problem of links. If the connection to the node you want to contact is broken (by, for example, a disconnected phone line), you receive an error message and whatever you sent is gone. However, this does not make messages totally useless. As you will see later on, TELL and SEND are extremely helpful in accessing the many services in BITNET. ********* * * Tools for Communication * * * * Part 3 * * * * Files ********* FILES are another way to communicate over BITNET. The text files and programs that you store on your computer can be transmitted to users at other nodes. People on VM/CMS systems would use a syntax like this: SENDFILE filename filetype filemode userid AT node For example: SENDFILE BITNET USERHELP A KRISTEN AT MARIST +---------------- +---------------- | | | +------- the address of the recipient | +------------------------- the file you are sending The syntax for VMS/JNET systems is quite similar: SEND/FILE filename.extension userid@node For example: SEND/FILE BITNET.USERHELP KRISTEN@MARIST +--------------- +------------- | | | +-------- the address of the recipient | +------------------------- the file you are sending The file sent is stored in the "electronic mailbox" of the recipient until he/she logs on. People on VM/CMS systems would use the RECEIVE or RDRLIST commands to process files sent to them in this way. People on VAX/VMS systems would use the RECEIVE command. You should check your local documentation for information on these commands. SEND/FILE and SENDFILE are useful for sending programs or large volumes of data over the network. However, they shouldn't be used for everyday communication. The MAIL utilities (covered below) are much more accessible. ********* * * Tools for Communication * * * * Part 4 * * * * Mail ********* Luckily the other form of BITNET communication has been given a very apt name: MAIL (often called "electronic mail" or "e-mail"). The simile is a good one. Just like regular postal service mail ("snail mail"), you provide an address, return address, and text. Software for sending mail software differs from site to site, so you will have to look in your local documentation for information. However, we may be able to shed some light on what most mail looks like and how it works. Mail files are really just specially formatted text files. The feature that makes them different is the "mail header". This tells a BITNET system and your mail software that it is not a regular text file. It looks something like this: The address of the recipient | The subject | | | Your address | | | | | Todays date | | | | | | | Date: Fri, 10 Sep 88 23:52:00 EDT <--+ | | | From: Ted Kord <BEETLE@JLIVM> <-----+ | | Subject: COBOL declared illegal <--------+ | To: Kristen Maryrose Shaw <KRISTEN@MARIST> <-----------+ An entire mail message would look like this: +---------------- Mail header | | Date: Fri, 10 Sep 88 23:52:00 EDT | From: Ted Kord <BEETLE@JLIVM> | Subject: COBOL declared illegal | To: Kristen Maryrose Shaw <KRISTEN@MARIST> + ======================================================================== + Have you seen the newspapers? Is this good news, or what? I think that | the ramifications are startling. This is one more step on the road to a | higher civilization. We may make it out of the Computer Age yet. Or is | it the Space Age? I keep forgetting... | +---------------- Mail text Mail has a number of advantages. The size of a mail file is limited only by your long-windedness (however, we don't recommend that you transmit anything longer than 3000 lines). If the person at the destination address is not logged on, the message will be stored until they read it. If the links to that particular node are disconnected, your mail will be held until it can get through. Also, mail is the only way you can communicate with people in networks outside of BITNET. The disadvantage of mail is that it is, indeed, slower than messages. The longer your mail file, the longer it will take to get from Point A to Point B. If your mail is less than 100 lines you won't have to worry about that. ********* * * Servers and Services * * * * Part 1 * * * * What the Heck is a Server, Anyway? ********* One of the first things experienced BITNET users will tell you about is the variety of file servers, list servers, relays, and so on. They might describe them to you as "virtual machines" or "server machines". This kind of talk makes plenty of sense if you are a typical computer nut, but for the novice this terminology might as well be Gaelic. Luckily, the concept is really very simple, despite everyone's efforts to make it confusing. A "server" is a userid much like yours. It may exist on your computer (node) or on some other BITNET node. The people who set up this userid have it running a program that will respond to your commands. This is a "server". The commands you send and the way in which the server responds to them depends on the particular program being run. For example, the servers NETSERV@MARIST and LISTSERV@BITNIC offer different types of services, and so require different commands. The various kinds of servers are described later in this document. You can send your commands to servers in one of two formats: MAIL or MESSAGE. Not all servers accept commands via both formats, but this information is included in the document BITNET SERVERS. People on VM/CMS systems would send commands something like this: TELL userid AT node command For example: TELL NETSERV AT MARIST HELP People on VAX/VMS systems using the JNET networking software would use this syntax: SEND userid@node "command" For example: SEND NETSERV@MARIST "HELP" Many servers can also accept commands via mail. Indeed, some will only accept your commands in that format. The syntax for the commands you send remain the same. You send mail to the server as if you were sending the mail to a person. The text of your message would be the command. Some servers will take the command as the first line of a text message, others require it in the "Subject:" line. Some servers will accept more than one command in a mail message, others will take only one. Here is an example of a mail message sent to LISTSERV@BITNIC requesting a list of files: Date: Fri, 10 Sep 88 23:52:00 EDT From: Rebecca Estelle Shaw <BECCA@YALEVM> To: Listserv <LISTSERV@BITNIC> ======================================================================== INDEX Throughout this document we will use examples where commands are sent to servers via message. However, for many of the cases we will present you have option of using mail. The choice is up to you. There are two particularly confusing aspects of servers of which you should be aware. First, servers in the same category (say, file servers) do not always accept the same commands. Many of them are extremely different. Others are just different enough to be annoying. There are many approaches to setting up a server, and everyone is trying to build a better mousetrap. The second problem is that there are many servers that fill two, sometimes three categories of server. For example, LISTSERV works as a list server and a file server. Many LISTSERVs have been modified to act as user directory servers as well. If you don't understand this terminology, bear with us. The best is yet to come... ********* * * Servers and Services * * * * Part 2 * * * * File Servers ********* Remember that a server runs on a userid much like yours. Like your userid, it has many capabilities, including the ability to store files. The program that a file server runs enables it to send you files from its directory, as well as a list of files available. These may be programs or text files. Those of you with PCs and modems would liken these servers to dial-up bulletin boards. You will generally send three types of commands to a file server. The first type is a request for a list of files the server offers. The second is a request that a specific file be sent to your userid. The third, and most important is a HELP command. The HELP command is very important because it is one of the few commands that almost all servers accept, no matter what the type. Because the commands available differ from server to server, you will often find this indispensable. Sending HELP to a server will usually result in a message or file sent to your userid listing the various commands and their syntax. You should keep some documentation handy until you are comfortable with a particular server. To request a list of files from a server, you will usually send it a command like INDEX or DIR. The list of files will be sent to you via mail or in a file. For example: VM/CMS: TELL LISTSERV AT BITNIC INDEX VMS/JNET: SEND LISTSERV@BITNIC "INDEX" To request a specific file from the list you receive, you would use a command like GET or SENDME. For example to request the file BITNET USERHELP from LISTSERV@BITNIC you would type on of the following: VM/CMS: TELL LISTSERV AT BITNIC SENDME BITNET USERHELP VMS/JNET: SEND LISTSERV@BITNIC "SENDME BITNET USERHELP" In many cases the files are organized into subdirectories or filelists. This can make requesting a file more complicated. As always, this makes it even more essential that you keep documentation about a particular server handy. Some file servers offer programs that you can run which will send commands to the server for you. ********* * * Servers and Services * * * * Part 3 * * * * User Directory Servers ********* User directory servers are offered for two reasons: One is to help you locate the network of address of a specific individual. Another is to help you find people in BITNET with various interests. You might call them the "phone books" of the network. There are a number of user directory servers in BITNET. Unfortunately, few of them accept the same commands or respond in the same way. Worse, there is no guarantee that an individual you are looking for is registered on a particular user directory server. There is (as yet) no central user directory server or requirement for people to be registered in one. Given these problems, you might wonder what good these servers are at all. They are disparate, disorganized, and often difficult to access. However, if you have a good idea of who or what you are looking for they can be useful. For example, let's say I am looking for the network address of Scott Free. He may or may not be registered with one of many user directory servers. Searching all of them would be time-consuming, considering the number of servers. However, this time I'm lucky, because I have some information: 1. Scott Free goes to Drew University. 2. The nodename for Drew is DREW. 3. There just *happens* to be a user directory server at Drew. The lucky point here is that Drew University has a user directory server. There is a good chance that Scott may be registered there. I retrieve the documentation for NAMESERV@DREW (remember the HELP command?) and send a query: VM/CMS: TELL NAMESERV AT DREW SEARCH/NAME Scott Free VMS/JNET: SEND NAMESERV@DREW "SEARCH/NAME Scott Free" Unfortunately, there is no entry for "Scott Free" and I am stuck. I call up Scott and ask him for his network address. However, just because Scott didn't register himself with the server doesn't mean you shouldn't. Some user directory servers allow people at other nodes to register themselves. Others do not. At this point we recommended that you register yourself with UMNEWS@MAINE (the Bitnauts List), a NETSERV user directory server, or NAMESERV@DREW. More information on these servers is available in BITNET SERVERS and via their HELP commands. I'll use NAMESERV@DREW as an example of how user directory servers take your registration. However, you should note that these commands are specific to this server. The syntax to register myself would be: VM/CMS: TELL NAMESERV AT DREW REGISTER first last keywords VMS/JNET: SEND NAMESERV@DREW "REGISTER first last keywords" For example: VM/CMS: TELL NAMESERV AT DREW REGISTER Chris Condon cars money VMS/JNET: SEND NAMESERV@DREW "REGISTER Chris Condon cars money" I entered only two keywords there ("cars" and "money") but I could have entered as many as five. These are useful when people make searches not for individuals but for groups of people with the same interests. For example, if I were looking on NAMESERV@DREW for people with an interest in "money", I would have used a command like this: VM/CMS: TELL NAMESERV AT DREW SEARCH/FIELD MONEY VMS/JNET: SEND NAMESERV@DREW "SEARCH/FIELD MONEY" ********* * * Servers and Services * * * * Part 4 * * * * Forums, Digests, and Electronic Magazines ********* The idea of mailing lists has been given new life with the advent of computer networks. Most of us are on mailing lists, be they for magazines, bills, or those silly pamphlets you get from your Senator. Computers have brought a whole new degree of speed and functionality to mailing lists, as you will see. In BITNET, mailing lists are used mainly to keep people with similar interests in contact. There are several formats in which this contact can take place. These are "forums", "digests", and "electronic magazines". FORUMS are a good example of how the utility of mailing lists has been expanded in BITNET. Let's say that you have subscribed to a forum for people interested in COBOL (gack!). How you could subscribe to such a list will be described later. Someone (anyone!) on the mailing list sends mail to a server where the list is kept. This server forwards the mail to all of the people in the forum. When mail from a forum arrives in your computer mailbox, the header will look much like this: Date: Fri, 10 Sep 88 23:52:00 EDT Reply-To: COBOL Discussion List <COBOL-L@METRO> Sender: COBOL Discussion List <COBOL-L@METRO> From: Ted Kord <BEETLE@JLIVM> Subject: No More Perform-Through-Varyings! To: Daniel Lawrence Shaw <DANIEL@YALEVM> ======================================================================== This looks a little confusing, but there really isn't much to it. In this example, Ted Kord ("From:") sent mail to the COBOL-L list address. This server then forwarded the mail to everybody on the list, including Daniel Lawrence Shaw ("To:"). Note the line named "Reply-To:". This line tells your mail software that when you reply to the note that the reply should go to the list... meaning *everybody* on the list. People will in turn reply to your mail, and you have a forum. This is usually very interesting, but it can lead to problems. First among these is the volume of mail you can receive. If you are in a very active forum, you can get 50 or more pieces of electronic mail in a single day. If you are discussing a controversial or emotional topic, expect more. Many people have a tendency to "flame". The speed and immediacy of electronic mail makes it very easy to whip out a quick, emotional, response, to which there will be similar replies. We advise you to take some time and think out your responses to forum postings before inadvertently starting a "flame war". DIGESTS provide a partial solution to the these problems. In this case, mail that is sent to a mailing list is stored rather than sent out immediately. At some point a the "Moderator" for the list organizes and condenses all of the correspondence for the day or week. He then sends this out to the people on the mailing list in one mailing. The drawback with this setup is that it requires a lot of human intervention. If the moderator gets sick, goes on vacation, or quits, activity for a particular digest can come to a screeching halt. ELECTRONIC MAGAZINES take the digest concept a step further. These mailing lists actually mimic the organization and format of "real" magazines. BITNET is used as a convenient and inexpensive distribution method for the information they contain. The frequency of distribution for these electronic magazines ranges from weekly to quarterly to whenever-the-editor-feels-like-it. This is the most formal, structured form of BITNET communication. Where a digest is simply a group of letters organized by topic, an electronic magazine includes articles, columns, and features. Perhaps the only feature of paper magazines that they do *not* include is advertisements. ********* * * Servers and Services * * * * Part 5 * * * * List Servers ********* In the previous section we mentioned servers that are used to control mailing lists. As you might guess, a server that performs this function is called a "list server". Most of these have the terribly original userid of LISTSERV. One of these servers can control subscriptions to many mailing lists. The most difficult concept behind list servers is the difference between a LISTSERV and its list-ids. When you subscribe to a mailing list, you send the appropriate command to a LISTSERV. When you want to communicate to the people on the mailing list, you send mail to the list-id. For example, there is a list named LIAISON. To subscribe to this list, you would send a command to LISTSERV@BITNIC. You could then correspond with people on that mailing list by sending mail to LIAISON@BITNIC. LIAISON is a list-id, a "satellite" of the LISTSERV. We mention this because many people make the mistake of sending commands by mail to list-ids. This annoys people to no end and creates a lot of unnecessary network traffic. To subscribe to a lists, you would send a LISTSERV a SUBSCRIBE command, which has the following syntax: SUBscribe listname your_full_name In this example, Kristen Shaw is sending LISTSERV@BITNIC the command to subscribe to LIAISON: VM/CMS: TELL LISTSERV AT BITNIC SUB LIAISON Kristen Shaw VMS/JNET: SEND LISTSERV@BITNIC "SUB LIAISON Kristen Shaw" If you misspell your name when entering a SUBscribe command, simply re-send it with the correct spelling. To delete her name from the mailing list, Kristen would enter an UNSUBscribe command: VM/CMS: TELL LISTSERV AT BITNIC UNSUB LIAISON VMS/JNET: SEND LISTSERV@BITNIC "UNSUB LIAISON" Those are the basic commands you need to know in order to access LISTSERV controlled mailing lists. However, LISTSERV has a multitude of features, so we (of course) encourage you to read the LISTSERV documentation. *NOTE* If you are on a VAXcluster, you should send SUBSCRIBE and UNSUBSCRIBE commands to LISTSERV via MAIL. ********* * * Servers and Services * * * * Part 6 * * * * Relays ********* Relay might be one of the tougher types of servers to understand. If you have used the CB Simulator on CompuServe you will catch on to the concept quickly. The idea behind Relay is to allow more than two people to have conversations by interactive message. Without Relay-type servers, this would not be possible. Let's set up a scenario: Kristen, Daniel, and Rebecca are at different nodes. Any two of them can have a conversation through BITNET. If the three of them want to talk, however, they have a problem. Daniel can send Rebecca messages, but Kristen can't see them. Likewise, Kristen can send Daniel messages, but then Rebecca is in the dark. What they need is a form of teleconferencing. Hence, Relays. Each of these users "signs on" to a nearby Relay. They can pick a channel, much like a CB. Instead of sending his messages to Kristen or Rebecca, Daniel sends his messages to the Relay. The Relay system then sends his messages to *both* Kristen and Rebecca. The other users can do the same. When they are done talking, they "sign off". Relays can distinguish commands from the text of your messages because commands are prefixed with a slash "/". For example, a HELP command would look like this: VM/CMS: TELL RELAY AT UTCVM /HELP VMS/JNET: SEND RELAY@UTCVM "/HELP" A message that is part of a conversation would be sent like so: VM/CMS: TELL RELAY AT UTCVM Hello there! VMS/JNET: SEND RELAY@UTCVM "Hello there!" When you first start using Relay, you must register yourself as a Relay user using the /SIGNUP or /REGISTER commands: VM/CMS: TELL RELAY AT UTCVM /REGISTER Daniel Shaw VMS/JNET: SEND RELAY@UTCVM "/REGISTER Daniel Shaw" You can then sign on. You can use a nickname, much like CB users have "handles". In the following example, someone is signing on to channel 10 with a nickname of "Fuzzyman": VM/CMS: TELL RELAY AT UTCVM /SIGNON Fuzzyman 10 VMS/JNET: SEND RELAY@UTCVM "/SIGNON Fuzzyman 10" You can then start sending the Relay the text of your messages: VM/CMS: TELL RELAY AT UTCVM Good evening. VMS/JNET: SEND RELAY@UTCVM "Good evening." Relay messages will appear on your screen like this. Note the nickname near the beginning of the message. When you send conversational messages to the Relay, it automatically prefixes them with your nickname when it forwards it to the other users: FROM UTCVM(RELAY): <Argyle> Hello Fuzzyman. You can find out who is on your channel with a /WHO command. In the following example, someone is listing the users on Channel 10. VM/CMS: TELL RELAY AT UTCVM /WHO 10 VMS/JNET: SEND RELAY@UTCVM "/WHO 10" The response from the Relay would look like this: FROM UTCVM(RELAY): Ch UserID @ Node Nickname FROM UTCVM(RELAY): 10 BONJJ524@CCNYVME ( Karl ) FROM UTCVM(RELAY): 10 UARE6641@NDSUVM1 ( Buzzard ) FROM UTCVM(RELAY): 10 QNDIPC41@HENTHT5 ( Wandjina ) FROM UTCVM(RELAY): 10 BITLIB@YALEVM ( Fuzzyman ) FROM UTCVM(RELAY): 10 EETDEE60@JLIVM ( Dr_Fate ) FROM UTCVM(RELAY): 10 PSYUY948@WATDCS ( John_Cage) FROM UTCVM(RELAY): 10 BECCA@YALEVM ( Rebecca ) FROM UTCVM(RELAY): 10 EDTCAI@CORNELLA ( Nightwing) When you are done with your conversation, you can sign off the Relay: VM/CMS: TELL RELAY AT UTCVM /SIGNOFF VMS/JNET: SEND RELAY@UTCVM "/SIGNOFF" There are several commands for listing active channels, sending private messages, and so on. When you first register as a Relay user, you will be sent documentation. You can also get this information with the /INFO command. To determine which Relay serves your area, send any of the Relays listed in BITNET SERVERS the /SERVERS command. Also, because of BITNET message and file traffic limits, many Relays are only available during the evening and weekends. ********* * * Beyond BITNET * * * * Part 1 * * * * Other Networks ********* BITNET, as you probably know, is not the only computer network in the world. What you might be startled to find out, however, is that when you have access to BITNET you also have access to many other networks as well. Unfortunately, the methods for communicating with people in these other networks are not as diverse or simple as the ones described earlier. This aside, BITNET links to other networks give you access to people and services you couldn't contact otherwise (or at least without great expense). That alone should make learning a bit about them worthwhile. Earlier on we compared BITNET nodenames to state abbreviations. We can take that a step further by thinking of BITNET as a country. The links between nodes (the "states") might be the highway system. Another network (a "country") is connected to our highway system at one point, which is called a "gateway". The guards (software) at the border are not particularly smart and will only let through mail. Interactive messages and plain files can't get through. The people in these other networks have addresses just like yours, but you need to specify something extra in order to get mail to them. A userid@node address is not enough, because that doesn't tell the BITNET mail software what network that node is in. Therefore, we can extend the network address with a code that identifies the destination network. In this example, the destination network is ARPANET, the code for which is ARPA. BECCA@SRI-NIC.ARPA +---- +------ +--- | | | | | +-------------------- the network | | | +---------------------------- the node | +---------------------------------- the userid That is about as simple as an address from another network gets. Generally they are more complex. Because of the variety of networks there can be no example which will show you what a "typical" address might be. However, you shouldn't have to let it worry you too much. If someone tells you that his network address is CONDON@VENUS.YCC.YALE.EDU, just use it like that with your mail software. As long as you understand that the mail is going to another network and that the transit time will be longer than usual, you should have few problems. ********* * * Beyond BITNET * * * * Part 2 * * * * More on Gateways ********* We talked a little about gateways in the previous section, but didn't get in to too much detail. This is because the subject can get a little complex at times. Or rather, understanding gateways isn't difficult, but interpreting network addresses that use them can be. In our previous example, an address for someone in another network looked like this: BECCA@SRI-NIC.ARPA This address tells your networking software that your letter should go to someone in another network. What you might not realize is that your networking software "knows" that the address for the gateway to ARPA may be at, say, JLIVM. It might extend the address to look something like this: BECCA%SRI-NIC.ARPA@JLIVM +---- +------ +--- +---- | | | | | | | +--------------- the node of the gateway | | | | | +-------------------- the network | | | +---------------------------- the node | +---------------------------------- the userid The gateway is a server machine (userid@node) that transfers files between the two networks. In this case, it is ARPA@JLIVM. Note that the "%" replaces the "@" from our previous example. This is because BITNET networking software cannot handle addresses with more than one AT sign (@). When your mail gets to the gateway the "@JLIVM" would be stripped off, and the "%" would be turned back into a "@". If this is so automatic, why do you need to know this? Because in many cases your networking software is not smart enough to know that the gateway for IZZYNET is at BLEGGAVM. If this is the case, you have to type out the whole address with all of the interesting special characters. In many cases gateway to a network may be in another network. In this example, we are sending mail to MICKEY at node PLUTO in SHOENET. The gateway to the network is in, say, ARPAnet. Our networking software is smart enough to know where ARPA gateway is, so the address would look something like this: MICKEY%PLUTO.SHOENET@SRI-NIC.ARPA +----- +---- +------ +------ +--- | | | | | | | | | +----- the network of the gateway | | | | | | | +------------- the node of the gateway | | | | | +--------------------- the network | | | +--------------------------- the node | +---------------------------------- the userid As you can see, these addresses can get pretty long and difficult to type. The only consolation is perhaps that your address probably looks just as bad to the people in the destination network! ********* * * In Conclusion * * * * Part 1 * * * * Suggested Reading ********* Don't stop here. This document was written to get you started as a BITNET user, but there is quite a bit more that you can read to use the network to its full potential. First of all, I recomend that you look over BITNET SERVERS, the list of all the different servers and services in BITNET. Likewise, I suggest that you subscribe to NetMonth. Instructions on how to get these files are located at the end of this document. Per usual, all of these files are free. It goes without saying (but I'll say it anyway) that you should read the documentation for whatever servers you try to use, even if you only look over a simple list of commands. It's better than nothing. Below are listed some files from the NETINFO FILELIST on LISTSERV@BITNIC which will provide further information on some of the topics I went over earlier. You can get them by sending the following command to LISTSERV@BITNIC via mail or interactive message: SENDME filename filetype. For example: SENDME MAIL MANNERS CHAT ANALYSIS - This is the original document by Henry Nussbacher which explained why old-style Chat machines were a danger to the network. This controversy prompted the develpment of Relay. BITNET CHARTER - The original BITNET Charter. BITNET OVERVIEW - A short document explaining the purpose of BITNET. MAIL MANNERS - Must reading!!!! This document explains the dos and don'ts of using electronic mail in BITNET (or any other network for that matter!). INFOREP LISTINGS - Each BITNET site has a person who is responsible for distributing information about the network and helping out users (the Inforep). If you don't know who your Inforep is, this document will tell you. LISTSERV GROUPS - A list of all the different mailing lists available via the BITNET LISTSERVs. ARPANET SIGS* - (ARPANET SIGS01, etc.) This is a list of all the mailing lists in the Internet, including many from BITNET. There is a certain amount of overlap between these files and LISTSERV LISTS. ******************************************************************************* To receive the latest version of BITNET USERHELP, send the following command to NETSERV@BITNIC, LISTSERV@MARIST, or LISTSERV@CMUCCVMA via mail or message: GET BITNET USERHELP Likewise, you can get the latest version of BITNET SERVERS by sending one of those servers the command GET BITNET SERVERS. If you want to get updates to BITNET USERHELP and BITNET SERVERS automatically, subscribe to NetMonth magazine, "The Independent Guide to BITNET". It is, of course, free. To subscribe, send the following command to LISTSERV@MARIST: SUBSCRIBE NETMONTH your_full_name For example: SUBSCRIBE NETMONTH Danny Shaw ******************************************************************************* This document (c) 1988 Christopher Condon and Yale Computer Center ******************************************************************************* A publication of the BITNET Services Library "Because We're Here."